<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 5 Development Kit v1.5.3 Readme</title>
<style type="text/css">
<!--
  P   { margin-left:  20px; }
  PRE { margin-left:  20px; }
  LI  { margin-left:  20px; }
  H4  { margin-left:  20px; }
  H3  { margin-left:  10px; }
-->
</style>
</head>

<body>
<div align="right"><small>
&copy; Copyright 2006 Contributors.
All rights reserved.
</small></div>

<h1>AspectJ 5 v1.5.3 Readme</h1>

<p>This release includes a number of bug fixes and enhancements (over 80).  The full list of resolved issues can be found with 
<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.5.3&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">
this bugzilla query</a>.
</p>
<p>
Notable changes since the 1.5.2 release include:
<br>

<h2>Pipeline compilation - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=146781">146781</a></h2>
<p>Until this release, the memory profile for AspectJ looked like this (time is along the X axis, memory usage is the Y axis)</p>

<code><pre>
     /\_
    /   \_
   /      \_
  /         \_
 /            \_
/               \
</pre></code>
<p>
The first phase (as we go up and up and up) is the compilation of every file - when the peak is reached we then start weaving files one by one, discarding them once woven and dumped to disk.

In 1.5.3 we don't compile everything up front - we compile and weave files one at a time.  Giving us this profile:
</p>
<code><pre>
  /\  /\  /\
 /  \/  \/  \
/            \
</pre></code>
<p>
Each peak is compiling a file, then it is woven, dumped to disk and the space recovered (the trough) - we then move onto the next file.

What does this mean?  The peaks are far far lower, so you need far less memory to compile a project.  For example, I have a 1000file project, affected by aspects at >750 join points.

For given values of Xmx, here are the times taken to compile it (on the command line) with AspectJ1.5.2:</p>
<pre><code>
Xmx  Time
512M 33seconds
256M 40seconds
220M 116seconds
212M OutOfMemory
</pre></code>

<p>The times gradually increase as the memory is reduced because the VM starts to thrash in garbage collection.

Here are the results for AspectJ1.5.3:</p>
<pre><code>
Xmx  Time
512M 33s
256M 33s
180M 33s
140M 33s
100M 35s
80M  43s
70M  OutOfMemory
</pre></code>

<p>So with 1.5.3, it isn't until around 80M that the VM starts to struggle with memory.  These savings will affect any code built from source: on the command line, in Ant,
or in AJDT.  It will not affect binary weaving - that is a future enhancement.</p>


<h2>Serviceability - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150487">150487</a></h2>
<p>As AspectJ grows in popularity, we find that it is becoming more difficult for users to come up with the small testcases
that recreate problems - the usage scenarios for AJ are becoming more and more sophisticated.  To help us work on
problems in these scenarios we have added a tracing and logging framework and improved our dump mechanism.  These traces and
dumps can be attached to bug reports.  In AspectJ 1.5.3 we have included
some <a href="http://www.eclipse.org/aspectj/doc/released/pdguide/index.html">documentation</a> on how to configure these new features.  Don't be surprised if you get asked
for an AspectJ trace on a future bug report!
</p>

<h2>LTW enhancements</h2>

<h3>User and System Configuration Files - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=149289">149289</a></h3>
<p>The <code>-outxml</code> option now generates a file named <code>META-INF/aop-ajc.xml</code>.
This no longer clashes with a user defined <code>META-INF/aop.xml</code> configuration file.
Both file names along with an OSGi-friendly <code>org/aspectj/aop.xml</code> (which can also be
signed) are used by default to configure LTW.</p>

<h3>Weaving Concrete Aspects Defined in aop.xml - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=132080">132080</a></h3>
<p>Concrete aspects defined using aop.xml are now exposed for weaving.</p>
 
<h2>Pertypewithin enhancement - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=123423">123423</a></h2>
<p>It is now possible to ask an instance of a ptw aspect which type it is 'attached' to.  The method:</p>
 <code><pre>String getWithinTypeName()</pre></code>
 <p>can be called on an aspect and will return the full qualified name of the type (eg. "com.foo.MyClass")
</p>

<hr>
<p>For information on bug fixes in AspectJ 5 v1.5.3, see the <a href="changes.html"> changes</a> document.</p>

</body> 
</html>
